Online payment transfer and identity management system and method

ABSTRACT

A payment transfer method for transferring funds from a payer to payee is provided, including designating a payee and specifying a payment amount and an account; debiting the funds from the account and crediting a first trust account; and identifying the payee by verifying responses received in response to one or more challenge-response questions defined by the payer. If the one or more responses are verified, a second trust account may be debited and a payee account credited with the payment amount. The first and second trust accounts may then be reconciled. There is also provided a payment transfer facility for transferring funds, comprising an application server for storing payment data relating to a transfer of funds and a notification server for providing a notification of the transfer of funds.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 12/954,814,filed Nov. 26, 2010, which is a continuation of application Ser. No.10/470,094, filed Mar. 24, 2004 (now U.S. Pat. No. 7,844,546), which isa national stage application from PCT/CA02/00107, filed Jan. 25, 2002,which claims priority from Canadian Patent Application No. 2,332,656,filed Jan. 26, 2001, the entireties of which are incorporated herein byreference.

FIELD OF INVENTION

The present invention relates to a system and method for online monetarytransfers. In particular, the invention relates to an online payment andidentity management system and method for delivering payments from afinancial institution over a global computer network.

BACKGROUND OF THE INVENTION

In the recent past a number of non-financial institution technologyfirms have bypassed banks by launching independent, Internet-basedperson-to-person (P2P) payment mechanisms. Most such services requireconsumers to register and debit a credit card or bank account beforesending a payment. Recipients of payments receive email notificationswith a specially coded link to register and authenticate beforereceiving several payment options, such as depositing into a bank orcredit card account.

Due to consumer demand and the “viral” nature of these mechanisms (bycompelling recipients to register in order to collect payments), uptakehas been significant. Consumers want a convenient Internet mechanism topay for online purchases and to replace “one-off” checks and cashpayments, both domestically and internationally. For example, considerthe millions of consumers who regularly wire money to family membersthat live abroad. For traditional financial institutions, the advent ofP2P payments represents both a threat and an opportunity. Banks risklosing customer relationships to third-parties that will quickly try toexpand their offerings into other traditional banking functions,competing with online checking accounts, business accounts and merchantpayment services.

With non-bank start-ups acquiring P2P market share, banks risk neverrecouping their massive investments in online infrastructure. Once anon-bank has entered the P2P payment transfer market, there is anopportunity to go beyond free P2P payments and offer consumers a fullrange of financial services, such as interest bearing sweep accounts,low-fee mutual funds and business accounts equipped to accept merchantpayment.

Unlike other pure-play Internet banks, which have spent millions ofdollars on advertising to promote their brands, non-bank P2P paymenttransfer firms have employed P2P payments to drive the initial adoptionof their service and, in the process, have significantly reduced theaverage customer acquisition cost. Once a non-bank P2P provider makesinroads into a bank's customer relationships, it becomes easier to gainfurther ground. As a result, financial institutions face the danger ofdisintermediation by aggressive non-bank up-starts. Demand for suchservices has been so high that some banks are offering P2P payments toposition themselves against third-parties and to acquire onlinecustomers. They include portals designed to aggressively capture newclients.

Competition with on-line banking services is arising from other paymentproviders in other forms as well, such as auction payments, online giftcertificates, event, micropayments and stored-value, payment processing,global payments and specialty consumer payments. Most of these P2Ppayment services are positioned to operate outside of the traditionalfinancial system. As such, consumers are forced to use third-party P2Pservices requiring personal financial information. This raises a numberof privacy and security concerns. Moreover, poor performance by anon-bank third party (which is typically not regulated to the extentthat banks and other financial institutions are) can undermineconsumers' perception of the reliability of on-line financial servicetransactions generally.

Furthermore, consumers are suffering from password fatigue, and many arelooking to simplify the manner in which day to day transactions andactivities are conducted. Consumers look to their banks, which havealready established the requisite credibility in financial dealings, tooffer additional services from their core banking relationship.

SUMMARY OF THE INVENTION

The present invention provides a person-to-person (P2P) payment platformand identity management system which facilitates online banking byallowing bank customers to send and receive money in real-time, with nospecial registration requirement outside of the customers' existingbanking relationship, and under the security, brand and control of theirown respective banks.

The invention provides an invisible application service provider in theform of a central clearing facility (CCF) which coordinates and managespayments for customers, nationally and internationally, through partnerfinancial institutions. According to the invention, customers sendpayments from within their online banking accounts, under their bank'sexisting authentication and security. Thus, customers can transfer moneydirectly from an existing online banking offering without setting upseparate accounts profiles and passwords. Customers trust banks to movemoney more securely than non-bank third-parties, and as such will morereadily respond to a payment solution offered under their bank'ssecurity provisions.

The CCF is invisible, and effectively operates under the bank's brand sothe bank retains the entire customer goodwill and developed brandrecognition. In addition, each payment, in particular those delivered bye-mail, prompts recipients who don't bank online to sign up for theirbank's Internet-based services to deposit payments directly into theiraccounts, thus increasing the bank's goodwill and facilitating thecross-selling of financial services. The e-mail payment option is ahigh-demand functionality that provides recognizable customer value andreplaces customer inconvenience with real-time transactions andconvenience to create more positive customer experiences. In addition tobeing able to initiate and receive payments using online bankingservices accessible via the web, customers can also utilize automatedteller machines (ATMs), wireless networks, telephone, and any otheraccess means provided by the financial institution to its customers.

In the preferred embodiment, to make a P2P payment the customer:

1. Accesses the online banking service;

2. Selects a recipient from a list of past payees or enters newrecipient information to create a new payee;

3. Specifies a payment amount, the account from which to draw the funds,and optionally an expiry date and a personalized message to therecipient; and

4. Confirms the transaction to authorize the bank to draw the funds,following which notification is sent to the recipient advising ofpayment with referrals to various methods of collection; and

5. Receives a confirmation message when the recipient accepts thepayment.

The recipient may:

1. “Web enable” an existing account or open online banking services;

2. Deposit the payment into any bank account;

3. Deposit the funds into a credit card account;

4. Request delivery of a paper check; or

5. Receive funds directly if the online banking service is an ATM.

The invention thus renders P2P payments under the control of the bankand eliminates the need for the bank's customers to use a third-partyservice. The bank controls all front-end consumer touchpoints includingend-user communications. The bank also has the ability to control howP2P payment capability drives new revenue sources, cuts costs andincreases market share, to create new revenue streams, reduceacquisition costs of new customers, increase marketing and cross-sellopportunities and reduce dependence on less efficient delivery channels.

The invention supports different frequencies of payment and multiplecurrencies, and can be deployed on all bank delivery channels, includingwireless services. All of these services can generate new revenueopportunities for online business, complemented with tools that enablethe bank to track and control usage.

The CCF's infrastructure is secure and scalable, able to employ thelatest encryption technologies and security measures to deliver soundand secure transactions. The invention allows the bank to determine andconfigure a wide array of security parameters, such as maximumtransaction limits, to suit each particular institution's risktolerances. If payments are undeliverable or unretrieved, the sender canhave the funds re-credited to their bank account or re-send the payment.A simple, yet robust data interface enables the bank's Internet serviceto connect quickly and securely to the CCF central facility with minimaldiversion of its technical resources.

The invention thus builds on the bank's relationship with its client, byadding new functionality to block out third-party online financialservice providers and strengthen the existing relationship. Moreover,the invention forecloses the need for account, ID, password and otherinconvenient administrative requirements that third-party financialservices providers must ask of consumers. The bank has the opportunityto leverage existing security and Internet payment infrastructures,replace consumer inconvenience with convenience and provide a facilityfor real-time email payments between customers of the same or differentfinancial institutions.

The CCF can coordinate payment transactions between customers banking atboth partner and non-partner financial institutions. It handles andstores all of the payment relationships among customers and manages theauthentication and approval of fund disbursements to payment recipients.

BRIEF DESCRIPTION OF THE DRAWINGS

In drawings which illustrate by way of example only a preferredembodiment of the invention,

FIG. 1 is a block diagram illustrating a real-time clearing network forP2P payments according to the invention,

FIG. 2 is a block diagram illustrating the payor-payee relationship inthe network of FIG. 1,

FIG. 3 is a block diagram illustrating user and data interfacesaccording to the invention,

FIGS. 4 a and 4 b are block diagrams illustrating an online P2P paymenttransaction where both payer and payee bank at a partner financialinstitution,

FIGS. 5 a and 5 b are block diagrams illustrating an offline P2P paymenttransaction where the payee does not bank at a partner financialinstitution,

FIG. 6 is a graph illustrating account netting at a partner financialinstitution,

FIG. 7 is a flow diagram illustrating the navigation path for an onlineP2P payment transaction where both payer and payee bank at a partnerfinancial institution,

FIG. 8 is a block diagram illustrating an identity management systemaccording to the invention,

FIGS. 9 a and 9 b are diagrammatic illustrations of a sequence of userinterfaces for a payer sending a payment,

FIG. 10 is a diagrammatic illustration of a sample of a message to apayee,

FIG. 11 is a diagrammatic illustration of user interfaces for payeeidentity authentication,

FIG. 12 is a diagrammatic illustration of a user interface for a payeeretrieving a payment,

FIG. 13 is a table illustrating user notifications generated accordingto the invention,

FIG. 14 is a table illustrating a request/response message set in theinteraction between the CCF and a partner financial institution,

FIG. 15 is a table illustrating a sample message sets,

FIG. 16 is a block diagram illustrating a preferred security system forthe CCF, and

FIG. 17 is a block diagram illustrating the relationship between logicalservice items in the system of the invention.

FIG. 18 is a block diagram illustrating an online P2P payment where thepayee receives payment at an ATM.

FIG. 19 is a block diagram illustrating an online P2P payment betweenbusinesses.

FIG. 20 is a block diagram illustrating an online P2P payment between acustomer and a retailer.

FIG. 21 is a block diagram illustrating a network for P2P paymentsbetween a payor and a payee in different jurisdictions according to theinvention.

DETAILED DESCRIPTION OF THE INVENTION

The system and method of the invention enables customers of a financialinstitution having access to banking services over a global computernetwork such as the Internet to initiate electronic paymentsconveniently and securely from their financial institution'sself-service delivery channels (Online banking service, ATM, Wireless,Telephone Banking) or the financial institution's branch. The inventionprovides financial institutions with an easy-to-integrate mechanism tofacilitate and manage person-to-person (P2P) payments, leveragingexisting fund transfer mechanisms that reside in the middleware of afinancial institution's banking service—the component that allowscustomers to move money between their own accounts—thereby avoidingsignificant back-end development. The invention extends an institution'sexisting infrastructure to facilitate funds transfers in and out ofconsolidation trust accounts established at partner financialinstitutions in each supported currency.

To process P2P payments, the invention helps partner institutions feedtransaction interfaces with the appropriate account numbers, parametersand authorizations. “Netting” processes balance the positions ofconsolidation trust accounts across all partner financial institutions.As a result, a private, real-time clearing network is created amongpartner institutions to settle electronic payments initiated and caughtby their customers. This allows financial institutions to maintaincontrol over their user interface by communicating with a centralclearing facility (CCF) 100, as shown in FIG. 1, throughindustry-standard messaging adaptors. The CCF manages the status andaccounting mechanisms to ensure that users at each end of a paymenttransfer are validated and notified throughout each step of thetransaction. The CCF features a secure, open front-end to allow usersthat do not currently bank at partner institutions to “catch” paymentsusing offline mechanisms that can reach and credit most accounts. Ifpayees do not wish to receive payment electronically, they can request acheck mailed to their address or, if receiving payment at an automatedteller machine (ATM), they can obtain the funds directly.

The CCF is based on an application service provider model that usesindustry-standard interfaces to integrate with partner financialinstitutions' existing systems. The invention acts as a common platformamong banks, interacting with each to support the efficient exchange ofP2P payments. The net result is one of ease and efficiency: eachfinancial institution establishes a one-to-one relationship with theCCF, eliminating the prospect of integrating disparate systems.

FIG. 1 illustrates an Application Service Provider Model which allowsfinancial institutions to rapidly deploy P2P payments on theirappropriate delivery channel (Online Banking, ATM, Wireless, etc.) Tomaximize security and to minimize the risk of fraud, payments are alwaysinitiated from within the authenticated layer of a partner financialinstitution's delivery channel. As a result, each payment that entersthe system for delivery originates from a trusted source. As shown inFIGS. 1 and 2, payees can receive their funds through the originatinginstitution 101 (Payee #1 201) or at another affiliated partner 102(Payee #2 202). Alternatively, customers banking at unaffiliatedfinancial institutions (Payee #3 203) can request payment throughoffline disbursement mechanisms offered at a secure Web site 300 poweredby the CCF 100. Partner financial institutions thus become a secure,real-time clearing network for P2P payments.

The architecture of the invention, illustrated in FIG. 3, consists ofdata and user interfaces that facilitate the movement of money betweencustomers. Behind the scenes, a secure CCF Web site 300 allows partnerinstitutions to manage security, marketing and customer supportcentrally through sophisticated administrative and reporting tools.

To enable the flow of funds between parties, according to the invention,consolidation trust accounts 401, 402 are established by each partnerfinancial institution 101, 102, as shown in FIGS. 4 a and 4 b. Accountsare held for each currency supported by the system. As a result, noexchange of funds between partner institutions is necessary to settleindividual payments between customers 410, 415. Instead, payments areexecuted by transferring funds from a customer's account 404 to theconsolidation trust account 401 at the originating institution 101. Ifthe payee 415 is a customer at a partner institution 102, receipt offunds is accomplished by transferring monies in real-time from theconsolidation trust account 402 at the payee's institution to thecustomer's account 405. Funds are available to the payee 415 forcollection immediately after payment notification is sent. Collectionmay be effected by a withdrawal from an ATM.

A front-end Web service 103 allows a payee 415 banking at anon-affiliated institution to specify an offline mechanism for paymentretrieval. The payee can select the transfer of funds to their accounts503 at CPA and NACHA member institutions (through an EFT 501 and ACH 502processor, respectively) or crediting to most common credit cardsthrough a remittance processor or payment gateway, as shown in FIGS. 5 aand 5 b. The invention also offers the option of a payee 415 requestingdelivery of a paper check by traditional mail for a nominal processingfee deducted directly from the amount they are receiving. Batch filepayments are securely transferred to processing agencies on a nightlybasis. EFT, ACH and credit card disbursements typically take between oneto four business days while check delivery takes from five to sevenbusiness days for North American delivery.

All communication with “offline” consumers 415 include prompts to driveadoption of a partner institution's online banking service. Through avariety of precautionary measures, described below, the inventionensures the security and validity of all payment requests anddisbursements and provides detailed reporting and transaction tracing toits partner banks

To move money between customers, the invention leverages the existinginternal funds transfer module utilized by institutions to facilitatecustomer transfers. With a few modifications, this piece of middleware(usually located on an application server) is enabled to executetransfers between a customer's account and a consolidation trust accountfor disbursements. The invention operates in reverse at the recipient'send. If a payee catches a payment at a partner institution, funds areimmediately transferred from a consolidation trust account into thepayee's own account.

To minimize liability, funds awaiting delivery are stored in accounts atpartner institutions in each supported currency. The CCF 100 controlsthe acceptance and disbursement of funds in these accounts, but does nottake direct ownership of the money. Instead, the trust accounts areactually internal or suspense accounts maintained by the partnerinstitutions 101, 102, 103, who earn the float on the funds awaitingdisbursement. The CCF 100 provides a detailed accounting of all themoney flowing in and out of these accounts. The CCF 100 acts as acontrol point, approving financial transactions undertaken by partnerinstitutions to move funds between customer and trust accounts inreal-time.

The CCF network, acts as a netting center. Instead of settling eachindividual transaction, the CCF 100 becomes a virtual clearinghouse,adding and subtracting inter-partner payables and receivables and thenproviding the partner institutions with settlement instructions tobalance the trust accounts 601, 602, 603, as shown in FIG. 6.

This netting activity is captured by a robust, double-entry accountingsystem. A continuous transaction journal at the CCF 100 mirrors each ofthe trust accounts maintained at partner institutions to facilitateauditing and reporting. The system is designed for resilience and willcatch accounting imbalances caused by the failure of one or moremid-operation system processes. The CCF 100 utilizes these accountingand reporting mechanisms to facilitate the following activities:

a) Daily reconciliation between the CCF 100 and its partnerinstitutions: The CCF 100 matches transactions in its journal againstthose tracked by each partner institution and then reports anyexceptions. Exception reports are investigated and addressed to ensurethat accounts are balanced.

b) Daily settlement reporting for partner institutions. The CCF 100calculates monetary obligations of each partner institution to all otherpartner institutions in the network based on the origin and destinationof completed payments. Each partner institution is provided with adetail list of all corresponding payments as well as a summary of moniesowed to the other partners. Partner institutions settle with each otheroutside of the CCF 100 by using existing large value fund transfermechanisms available in their jurisdiction.

c) Feed the CCF's 100 finance and accounting systems: The transactionjournal generates a number of accounting and control system reports.

d) Provide audit reports: Where an audit is required, the CCF 100 usesthe transaction journal to generate accounting reports for all findsthat have yet to be disbursed. The CCF 100 also retains historicalrecords to facilitate account investigations.

e) Exception reporting: Partner institutions can send their client fundtransaction log (covering activity in their consolidation trustaccounts) to the CCF 100 to match these against the transaction journalfor inconsistencies. If the two reports do not balance, an exceptionreport is generated so that the situation can be investigatedimmediately and corrected if necessary.

Where the payer 410 and payee 415 are located in differentjurisdictions, requiring a currency exchange, the settlement procedureincorporates a foreign exchange facility which maintains trust accountsin each jurisdiction in the local currency.

FIG. 7 illustrates the payer and payee navigation paths where both payer410 and payee 415 are existing clients with Web banking privileges atpartner financial institutions.

As shown in FIG. 8, the invention provides an identity management systemthat leverages secure payment relationships between remote consumers.Each customer (payer 410 or payee 415) is granted a unique identity thatis assigned when he or she first registers with the service. A payer 410can establish a list of recurring personal payees 415 as required. Whilepayee records are immediately added to the CCF database, they are notauthenticated until they correctly answer one or more challenge-responsequestions defined by the payer and after successfully logging onto hisor her institution's online banking service or other delivery channel815. This process establishes both the payee and the specific “channel”where the payee has opted to deposit funds. If a customer wishes tocredit an account at another institution on a subsequent transaction,the customer must re-authenticate with the original challenge-responsequestions before that new “channel” is secured. The challenge-responsequestions may include the input of a secret code provided by the payer410 to the payee 415. In another embodiment, identity management ishandled entirely by the authentication procedures of the partnerinstitutions, thus allowing the institutions to manage the risk of fraudentirely by implementing their own security standards without the use ofa payer-defined challenge-response question.

The identity management aspect of the invention provides the followingadvantages:

a) Increased system security: Customer account information from partnerinstitutions is never stored at the CCF facility. The CCF 100 completesall processing against its own internal IDs, which are established wheneach customer auto-enrolls to send payments. Each CCF internal ID isreferenced against an institution's customer user ID for messagesynchronization.

b) Transaction tracing: The CCF 100 holds a unique identifier for eachcustomer it encounters. The CCF layers contact information for eachcustomer identity in its database to facilitate notifications andauthorizations. Each identity is cross-referenced back to the partnerinstitutions' customer IDs to facilitate transactions, reporting,support and tracking without compromising personal information.

c) Enhanced consumer experience: The identity management model of theinvention enables customers to retain “trusted” payment relationships tosimplify future payments. These payee relationships are delivered ondemand to a partner's system to encourage quick re-use of the “trusted”payee for subsequent transactions, thereby enhancing the userexperience. These payee relationships can be deployed to other bankchannels, such as WAP-enabled phones, through the message interface, tolaunch subsequent payments first established through a partner's Webbanking service.

d) The consumer is validated on each channel before moving funds: Sincethe payment system offers customers a variety of mechanisms for“catching” payments, one may choose an account at a different partnerinstitution into which funds are deposited on a subsequent visit. Inthis case, the payment system again asks the same challenge-responsequestions before validating the new payment channel, at which point thenew account is deemed “trusted” and added to the consumer's identity.

Through the identity management function, other fraud protection andsecurity measures are employed by the payment system in addition to theauthentication of payment relationships.

a) Institution-controlled security parameters: Each institution candefine security parameters that govern transactions originating fromtheir banking service. These default parameters include transactionlimits, daily transaction limits per customer and the maximum number ofdays before an unretrieved payment is sent back to the payer forrecrediting.

b) Initiation of payments: All payments originate from within anauthenticated banking environment (for example, web, telephone, wirelessnetwork, ATM, or another access point to banking services) at a partnerfinancial institution. One can initiate an email payment only whenlogged on, ensuring that such transactions are validated back tocustomer bank accounts at partner institutions.

c) Receiving payments: The recipient must authenticate and correctlyanswer one or more challenge-response questions before the retrieval offunds is allowed. The partner institution controls the number and typeof challenge-response questions the payee must answer before therelationship is authenticated.

d) Audit trail: A detailed audit trail records all pending andhistorical payments.

e) Transaction integrity: The CCF's transaction management serviceguarantees that database transactions are completed accurately. If anyone operation fails, the entire set of operations is rolled back. Aglobal transaction identifier is created when a client applicationinitiates a transaction. The transaction service monitors participantsfor failures and inactivity. Records accessed during a transaction arelocked until its completion. A rollback procedure is executed when atransaction must be stopped due to unexpected client termination,server/network failure or other events that may interrupt end-to-endcompletion of the transaction. This procedure checks recently activetransactions and then determines whether it should be rolled back orcommitted.

A number of measures ensure the security of customer data. The CCF 100does not store a partner institution's customer account numbers. Datarelated to customers banking at unaffiliated institutions are stored ina secure database, which is located behind a firewall and encryptionprocesses. Administrative user IDs and passwords are stored behind afirewall in an encrypted format. Administrative users can definemultiple security groups and access restrictions in accordance to jobfunction. Challenge-response questions provide an extra mechanism forauthenticating the payee in addition to existing logon processes at thepayee's own Web banking service. The network connecting partnerinstitutions, administrative users and unaffiliated consumers is dividedinto several isolation and security zones with restricted access amongzones. Industry-standard measures are used throughout the network toensure security. Intrusion detection devices, traffic encryption, packetinspection and application proxies minimize risk to the network. Allcommunications between the CCF 100 and its partner institutions takeplace over a dedicated line or VPN and are encrypted.

A number of exception processes and error handling mechanisms furtherensure the CCF's integrity:

a) Undeliverable payments: If the payer specifies an invalid emailaddress and the resulting notification bounces back to the server, thepayer is automatically contacted and presented the option to re-credithis or her account or correct the recipient's email address to resendthe payment notification.

b) Unretrieved (or expired) payments: With the CCF's back-officeadministration tool, affiliate institutions can each define a maximumperiod of time before a payment expires if uncollected by a payee. On adaily basis, the system will run a task to detect all expired payments.Notifications are sent to the payer and payee indicating expiration. Thepayer is then presented with the option to send it again or transfer thefunds back into a specified account.

c) Cancelled payments: At any time before retrieval, the payer 410 cancancel a payment. After logging on to the originating Web bankingfacility or other delivery channel, the payer 410 simply cancels thepayment transaction by indicating the account to be credited and sendingan optional memo indicating why the payment was cancelled. Theinstitution's banking service then sends a message to the CCF 100containing the payment reference number. The CCF 100 will verify thatthe payee 415 has not retrieved the funds and the system will change thepayment status to ‘Cancelled’ while sending notification to the payee415.

d) Rejected payments: The payee 415 can reject a payment transactionfrom within the authenticated Web banking environment of an affiliateinstitution or upon authentication at the CCF Web site 300. If thepayment is rejected, an email is sent to the payer 410 with instructionsto log on to his or her Web banking facility or other delivery channelto select an account to re-credit the funds.

e) Invalid account information: If payees 415 select an offlineelectronic method to catch a payment, there exists the potential thatincorrect account information might have been entered despite theprocesses performed at the interface layer. Transactions that cannot becompleted through the ACH/EFT/RPS processing facilities are returned tothe CCF 100. The payee 415 is then notified of the problem and given anopportunity to re-enter the account information or specify an alternatemeans of retrieval. If the subsequent attempts fail to deposit the fundsinto the payee's designated account, the funds are returned to the payerand both parties are appropriately notified.

f) Reconciliation process: On a daily basis, each partner institution101, 102, 103 sends a file containing all transfers to and from thepartner's consolidation trust accounts. Payment reference numbers arereconciled against information stored at the CCF 100.

With reference to FIGS. 7, 9 a and 18, a P2P payment may take place asfollows:

To initiate a P2P payment, the customer logs onto the partnerinstitution's online banking service 901 via the web, telephone,wireless network, ATM (as shown in FIG. 18), or other means at 701 inFIG. 7. The customer selects 702 the payment feature 902 from thefinancial institution's menu of services and chooses from their list ofprior payees. To enter a new recipient, the customer is prompted toenter the payee's name and e-mail address 703, if notification of thepayment is to be delivered by e-mail to the payee. The customerspecifies 704 payment amount, the account from which to draw the fundsare specified, and optionally an expiry date and a personalized messageto the recipient as shown at 910. To add an additional security measureto validate the recipient before fluids are disbursed, the customer cancreate one or more challenge-response questions and provide therequisite answers as shown at 911 in FIG. 9 b. Referring to FIG. 18, Ifthe customer 1801 logs on using an ATM, these payment details arecommunicated from the ATM to the ATM switch 1802. As well, the customeris authenticated using the institution's security standards; where thecustomer logs onto an ATM, authentication of the customer is handled bythe ATM switch 1802 in communication with the host system 1803 of thebanking service. The payment details are communicated by the ATM switch1802 to the CCF 100 (not shown in FIG. 18), which assigns a uniquepayment reference number and communicates this number to the ATM switch1802. The ATM switch 1802 then communicates with the host system 1803,and the customer's account is debited for the payment and the financialinstitution's trust suspense account is correspondingly credited. TheATM switch 1802 communicates with the ATM to cause the ATM to provide areceipt to the customer 1801, which includes the payment referencenumber, then communicates the successful completion of this portion ofthe transaction to the CCF 100. Notification is delivered to therecipient announcing the payment 721.

The recipient's personalized notification indicates the amount beingpaid, from whom, the name of the originating institution, as well asoptions for collection. In one embodiment, the notification takes theform of a personalized e-mail 1001 to the recipient, as shown in FIG.10. The payment's originating institution may promote its servicesthrough banner advertisements in the body of the message. The inventionprovides multiple options for retrieving finds, as shown in 1103 in FIG.11.

If the recipient already banks online with a partner institution and haspreviously received an electronic payment via this system, the recipientmay select from a list of payment options to log onto their online bankaccount straight from a link provided in the e-mail notification ofpayment at 1102 in FIG. 11, optionally identifies the payment byreference number and answer the challenge-response question if it is thefirst payment from that particular sender. This validates therelationship between both parties. The recipient may choose to log ontotheir online bank account 723 using another communications protocol,such as via a wireless network, telephone, or ATM.

If the recipient banks online with a partner institution, but isreceiving a P2P payment for the very first time, a link in the e-mailnotification sends the customer to a directory of CCF partnerinstitutions. Recipients can use their online banking service toinstantly credit any of their accounts. The registration process isfully automated.

Recipients, who are not currently banking online, are prompted to either“Web enable” their existing accounts at a CCF partner institution (suchas the sender's bank) or apply for an account with online access atanother partner, as shown in 1201 in FIG. 12. To facilitate thisprocess, the CCF Web site provides all appropriate links andinformation. Currently, the enrollment process for acquiring onlinebanking services at a financial institution can take anywhere from a fewminutes to a few weeks, especially if passwords must be issued by mail.In the case of a delay, the CCF will hold the payment for theappropriate number of days; customers must wait for their account to beactivated at a partner institution. An e-mail reminder is sent to thecustomer to activate the service and retrieve their funds.

The recipient then selects the account into which to deposit the funds726. The institution validates the recipient's identity, andcommunicates the payment details to the CCF 100, which verifies thepayment and issues permission to disburse the money. The financialinstitution then debits a suspense account, and credits the recipient'saccount for the payment. If the recipient chooses to receive the fundsdirectly, a cash account is credited instead and the funds aredisbursed. Once the funds credit or disbursement is completed, the CCF100 is informed of the successful completion. The funds may be advancedimmediately by the recipient's institution, because the funds have beenguaranteed by the originating institution's verification of the identityof the sender.

The complete payment transaction is decentralized; the first component,the initiation of payment, is controlled by the sender's financialinstitution, and the second component of the transaction, the receipt ofthe payment, is controlled by the recipient's institution. It can alsobe seen that due to the authentication of each party to the transactionindependently, by each party's own financial institution, the payer'sidentity does not need to be known by the payee in order to effectpayment. The payer may use an alias or e-mail address only, if desired,in communication with the payee.

The funds may alternatively be deposited to a credit card or other bankaccount. To provide maximum payment reach, the CCF 100 processespayments to non-partner accounts on a fee-for-service basis. Recipientsmay opt to deposit the payment into a credit card or other bank accountnot sponsored by a partner institution. Recipients are directed to theCCF Web site 300, where they can register for the service. Whenregistered, recipients specify a credit card or bank account into whichto deposit the funds. Such requests are batched and sent each day topayment processing services to be credited via ACSS, ACH and RPSservices.

Payment recipients who require a check or are uncomfortable makingtransactions online, can request the CCF 100 to issue a paper check formail delivery. At every turn, payment recipients are prompted to use apartner institution to receive their funds. If they choose to receive apayment using a non-partner mechanism, the CCF 100 will facilitate thetransaction through its Web site.

In a further embodiment, payments may be made to a recipient who doesnot have a bank account via an ATM and is not registered with the CCF100. The ATM, rather than requiring a bank card to initiate anytransaction, provides direct access to the menu option to receive a P2Ppayment. To verify the identity of the recipient, since there is no bankcard authentication, preferably the recipient must at least respond tothe challenge-response question 724 and/or provide the payment referencenumber. The ATM will communicate these payment details to the CCF 100,which will verify the payment and issue permission to disburse themoney.

The CCF's notification server 550, shown in FIGS. 4 b and 5 b, providesinformation to both parties regarding the status of a paymenttransaction. Each of the messages is based on a standard template, sothat the payee receives the same message irrespective of the originatingpartner institution. Notifications have multilingual capabilities. FIG.13 shows options 1301 for end-user notifications generated by the systemof the invention.

Payments between businesses and businesses, or between businesses andcustomers, follow the same format as the payments described above.However, if a large number of payments are transacted, it becomesimpracticable for a business to log on and collect each payment as theyarrive. Instead, business customers of participating institutions mayenroll in a commercial registry which provides a funds consolidationfunction.

Business customers who choose to participate in the commercial registryare first qualified for participation and enrolled by their institution.The institution in turn provides this certified business customerinformation to a CCF commercial registry, which is used to validate andcertify the identity and contact information of the business company asa legitimate operating concern with a bona fide banking relationshipwhen payment transactions are initiated. Preferably, this informationwill include the official name, address, and contact information of thebusiness, trade name, and a verified e-mail address.

A subset of this financial institution-certified information isavailable to any individual or business that receives a payment requestor wishes to originate a merchant payment to this business customer,which provides assurance that the funds are being directed to theappropriate recipient.

A business customer may generate a payment request for one of its owncustomers by delivering an invoice and directing the customer to accesshis or her own financial institution services to effect payment to thebusiness as shown in FIG. 19. The business customer 1901 logs onto itspartner institution's online banking service 1902 and enters invoicedata either manually or by importing a payment file 1903 from a thirdparty accounting tool. The partner institution transfers the paymentdetails 1904 to the CCF 100, which assigns a tracking number andoptionally a universal resource locator (URL). The payment details arestored by the CCF 100, which then notifies the customer (payer) 1950 ofthe invoice. Preferably, the invoice is delivered by e-mail 1908 anddirects the customer 1950 to its partner institution's online bankingservice 1951. The customer may choose to approve payment immediately, ormay choose to view additional information regarding the invoice if suchinformation is available (for example, through the URL or anotherhyperlink) When the payment is approved, the CCF 100 completes thepayment in the manner described above and issues a receipt 1905, 1955 toboth parties. The business customer can then log onto its institution'sonline banking service 1902 to collect the funds and optionally exporttransaction statements 1906 to a third party accounting tool.

In another embodiment, shown in FIG. 20, no invoice is issued to thecustomer 2001, but the customer initiates the payment as part of aretail transaction in an online environment. For example, in a web-basedauction, the customer clicks on a “pay me” link appearing in a vendor'sauction listing 2002. Clicking on this link passes payment details 2003to the CCF 100, together with a token identifying the vendor 2050 and anoptional return URL. In the meantime, the customer is referred to apartner institution, approves the transaction, and the payment iscompleted as generally described above.

When the payment is made, the business customer 2050 can choose toreceive notification of each payment, and choose a deposit account andcollect the funds. Alternatively, because it is impractical for thebusiness customer to respond in this manner to a large number ofpayments, the payment system can be configured to consolidate funds byaccumulating cleared payments, and then sweeping the accumulated fundsinto a default commercial account at the end of the period. The fundsmay be swept into the commercial account on a periodic basis, such as adaily basis, or once the accumulated funds reach a certain thresholdvalue or the number of payments reaches a threshold number.

Business-to-business payments, for example, payment by a businesscustomer to a supplier, may also be effected using this system. If therecipient business is also enrolled in the commercial registry, the CCF100 will handle the payment using the funds consolidation method. Toenable transactions between two or more payment systems, for example twodomestic payment systems in a cross-border transaction, the financialinstitutions in each country are affiliated with a regional CCF 100 inthat country. Customers in each country use their partner institution'sauthentication process to log into their selected delivery channel(Internet, telephone, ATM, wireless, etc.). Each regional CCF isresponsible for storing, sending and receiving all payments whichoriginate and terminate at that site. Only a limited amount of data isreplicated between the regional sites when it is required to perform afunction. Preferably, any replication is carried out based on anasynchronous remote XML request, which carries the data to bereplicated. There is therefore no requirement for real time datasynchronization between regional CCF sites.

Referring to FIG. 21, an international CCF site 2101 is primarilyresponsible for coordinating the exchange of data between the regionalCCF sites. The international CCF also maintains a global directory ofaffiliated institutions. A foreign exchange (FX) facility 2110 maintainsa database of exchange rates 2111 and manages currency exchangetransactions, and maintains trust accounts 2115, 2120 in eachjurisdiction in the local currency.

For an international payment, the CCF switch 2130 at the point of originof the payment queries the global directory to determine whichinstitution 2141, 2142, 2143 and CCF regional switch 2140 has beendesignated by the recipient. If a currency exchange is required, the CCFswitch at the point of origin also communicates with an FX facility todetermine the exchange rate and book the currency exchange. The paymentdetails are replicated by the regional CCF 2130 to the regional CCF 2140of the recipient using an asynchronous messaging mechanism.

At the point of destination, the regional CCF 2140 delivers a paymentnotification to the intended recipient. The notification includes anencrypted payment reference number, which contains a paymentidentification code to identify the payment's point of origin. Thenotification directs the recipient to an affiliate institution to claimthe payment. The recipient logs onto the selected banking service andreceives the funds. Funds transfer occurs by means of transfers betweensuspense accounts and customer accounts, as described above.

Settlement between financial institutions takes place on a periodicbasis, for example at the end of each business day. Based on agreedcut-off times, the CCF 2101 provides each member institution 2131, 2132,2133, 2141, 2142, 2143 with reconciliation and settlement information.This data is used to reconcile transactions between the CCF 2101 andeach institution, as well as to determine the institution's monetaryobligations to other members in the network to effect settlement.

Where the institutions are located in different jurisdictions,settlement takes place between the originating and destinationinstitutions using the exchange settlement facility's accounts in thejurisdiction of each institution 2115, 2120, based on settlement adviceprovided by the CCF 2101. With reference to FIG. 21, the internationalCCF site 2101 is networked to a number of regional CCF sites. Theparticipating financial institutions (2131, 2132, 2133, 2141, 2142,2143) in each region are connected to its corresponding regional switch2130, 2140. Each of these institutions maintains a suspense account. TheFX facility has an international site networked with local sites, whichare in communication with each of the institutions in the same region.Each local FX site maintains a local currency settlement trust account2115, 2120 on behalf of the international CCF, through which all foreignexchange settlement will take place.

The networked CCFs provide settlement advice to the financialinstitutions so that the institutions may make aggregate transfers.These transfers are made to the local currency settlement trust accountsin the local currency, and not to the other institutions. Each transfermay be carried out by means of wire payment to provide finality oftransfer.

Access to functions beneath the user interface layer is providedutilizing a request/response XML-based message set. All communicationsare encrypted and signed. FIG. 14 illustrates high-level interactionbetween a partner institution's middleware 1401 and the CCF facility1410 to reconcile a payment to a new payee. FIG. 15 shows a number ofpossible message sets 1501 and explains how they are used to facilitateP2P payments. Each message set consists of a request initiated by apartner institution's middleware and a response returned by the CCF 100.These messages invoke additional system processes at the CCF 100.

According to the invention, the use of specific delivery channels isleft to the discretion of the partner institution. While the primarychannel is online banking, the service can be extended to telephonebanking and host-based ATMs.

Currently, consumers access Web banking services almost exclusively on abrowser residing on a personal computer. As Internet-enabled appliancesgain mass acceptance and continue to improve in terms of cost,connectivity, display, memory and processing capabilities, financialinstitutions will offer banking services through these devices. A singleinterface is required between the institution and the CCF 100 to supportmultiple Web-enabled devices. Java-based adapters allow institutions tocommunicate internally with other application servers that supportspecific devices.

Once financial institutions have implemented P2P payment capabilities ontheir Web banking service, they can utilize the message-based interfaceof the invention to support a synchronized, multi-channel deliverystrategy to offer users of non-PC devices access to the same list ofpersonal payees from their Web channel. Due to current data-entryinterface limitations in mobile devices (such as WAP-enabled cellphones, ATMs and telephone banking VRUs), it may be more practical todisplay a customer's pre-existing list of personal payees through thesechannels. The identity management system of the invention has thecapability to store lists of customers' established payment linkagesfrom prior payment requests.

For example, a consumer wants to re-credit an acquaintance for pickingup the dinner tab at a restaurant. This payee could log onto theirinstitution's wireless banking service, select the payment recipientfrom his or her list of past personal payees and enter a monetary amountand a specific account from which to draw the funds. Upon receipt of thepayment request, the CCF 100 immediately launches a payment notificationand the recipient can authenticate to deposit the funds the next time heor she accesses email. Mobile P2P payments will help institutions extendtheir wireless banking platforms, increase adoption and leverage theirinvestments in that channel.

Most banks currently offer some form of telephone banking servicethrough an automated voice response unit (VRU). Typically, customersthat authenticate with a PIN number can select and pay merchants from apreviously determined personal list. A list of pre-existing personalpayees stored by the CCF is akin to the merchant list concept in theprevious example and can be presented on the VRU platform through theCCF's XML messaging interface.

Similarly to Web and telephone banking delivery, the institution candisplay a customer's existing list of personal payees on ATMs forconvenient re-use by leveraging the messaging interface and identitymanagement system of the invention.

A Web-based publishing tool is supplied with the administration suiteenabling marketing managers at institutions to control the email bannersthat appear on these notifications. The CCF can send notifications toemployees within partner institutions. Notification functionality isdetermined by the institution through the CCF's Web-based administrationand reporting tools.

The invention provides a secure Web-based interface for staff at partnerinstitutions to manage customer service, business planning, marketingand key system and security parameters. Different job categories allowbank staff varying levels of access to information and functions of theinvention.

The financial institution's system security administrator possessesroot-level access that grants privileges to other staff. Thisadministrator can define and update certain system-wide securityparameters that govern transactions originating from the institution'sWeb banking service. These parameters include maximum transactionlimits, daily transaction limits per consumer and the maximum number ofdays before an unretrieved payment is sent back to the payer forre-crediting.

An institution's Web service channel manager can publish and updatemarketing messages that appear on CCF-triggered email paymentnotifications. As well, the channel manager can view all multilingualemail templates delivered to customers to facilitate payments and directcustomers to URLs that open online banking services or logon to existingaccounts. This person can also view all system-generated business metricreports that yield rich statistics, such as payment volumes, customeractivation levels, methods consumers use to catch payments, averagepayment amounts and the average time between payment initiation andfinal settlement.

Customer service representatives (CSRs) can make inquiries usingtransaction confirmation codes that facilitate payment tracing. Theinvention provides a complete audit trail for any activity related to aparticular customer or payment transaction within a certain time period.CSRs can provide support by viewing payment-processing information.Detailed lists of system-generated messages (and explanations) as wellas daily schedules for processing are some of the items that CSRs canaccess in responding to customer inquiries. The system also features CCFbulletin boards to publish messages that could impact upon customers'immediate use of the service.

The architecture of the invention, illustrated in FIG. 16, providesperformance, security, availability and scalability. The inventiondelivers protection from unauthorized external or internal access byimplementing several industry standard mechanisms including: multi-layerfirewall structure 1610 a, 1610 b; secure access lockdown of Web servers1612 and mail servers 1615; extensive intrusion detection; documentationsecurity and escalation procedures. The invention supports a clusterserver architecture designed to provide maximum fault tolerance,performance and scalability.

The invention uses XML based request/response messaging to exchangeinformation with financial institutions. Each XML message consists of astandard header and variable body sections. The system is designed tosupport versioning and to be backwards compatible as new features areadded or new means of access to online banking are provided tocustomers. For example, where an institution requests a paymenttransaction on behalf of its client the financial institution's ownInternet banking application presents the appropriate form to thecustomer, gathers and validates the data entered by the customer andformats the XML request such as:

<?xml version=“1.0” encoding=“utf-8”?><!DOCTYPE REQPMTBGRQ SYSTEM “file://reqpmtbgrq.dtd”>

<CCFREQUEST>

<MESSAGEHDR>

-   -   <MESSAGETYPE>8</MESSAGEGETTYPE>    -   <MESSAGETYPEVER>1.1</MESSAGETYPEVER>    -   <FIID>10</FIID>    -   <TRANTOKEN>X35JCBE</TRANTOKEN>

</MESSAGEHDR>

<MESSAGEBODY>

-   -   <FIUSERID>56450983045034</FIUSERID>    -   <CUSTOMERID>B7856434U4</CUSTOMERID>    -   <CURRENCY>CAD</CURRENCY>    -   <PMTAMOUNT>65.00</PMTAMOUNT>    -   <EXPIRYDATE>2000-09-16-23:59:00.000000</EXPIRYDATE>    -   <MEMO>Here is the money I owe you for dinner. Thanks</MEMO>

</MESSAGEBODY>

</CCFREQUEST>

The invention executes the appropriate transaction and returns aresponse to the Financial Institution using a similar format.

The preferred production system runs on a hardware platform under theUnix Operating System and uses commercially available and reliableApplication and Database Management Software 1625, 1620. The system ishoused in data center facility. The preferred embodiment of theinvention employs Java 2 Enterprise Edition technology coupled with anenterprise relational database system using a clustered, fault-tolerantconfiguration which is both scalable and extensible, providing theability to easily manage and update with additional features andservices as required.

Applying multi-tier distributed design patterns, the invention iscomposed of four logical service items (presentation 1701, messaging1702, business 1703 and data 1704), shown in FIG. 17, that arephysically distributed through several redundant, fault-tolerant andbalanced implementation systems. Presentation logic is the link betweenthe client interface and the business logic. Using JavaBean and Servletspecifications, the presentation logic components communicate with thebusiness logic components (EJBs) 1703 a, 1703 b, 1703 c . . . 1703 n.The presentation logic 1701 is based on the concept of heterogeneousclient interfaces, allowing both browser and non-browser interfaces tocommunicate with the CCF 100. The messaging layer 1702 is the linkbetween the partner institution and the business logic. This layerconsists of a number of Java servlets 1702 a, 1702 b, 1702 c . . . 1702n responsible for parsing and validating XML messages and the invocationof appropriate business components. Business logic is processed by adistributed middleware server with enabled clustering and object cachingbased on the Enterprise JavaBean standard. Both business logic andfunctional rules are maintained in a series of session beans and entitybeans that are located on networked systems. Enterprise JavaBeans (EJBs)communicate with the associated data media and apply any relevantbusiness rules. Data media and its associated transactions aremaintained in an enterprise database system supporting both theencryption of resident data and the features that promote redundancy andreliability.

The following technologies may be employed in the implementation of thesystem and method of the invention:

Java 2 Standard Edition

Java™ 2Standard Edition (J2SE™) is a Web platform that enables rapiddevelopment and deployment of software applications across multipleoperating systems and platforms with fewer defects than similartechnologies. With significant performance gains and improved Webdeployment mechanisms for enterprise, client-side Java applets andapplications, J2SE Version 1.3 includes a new client Java virtualmachine (JVM™), tuned libraries throughout the platform and enhancementsto the Java Plug-in software for improved Web browser delivery.

Java Beans

Developed in collaboration with industry leaders, JavaBeans are aportable, platform-independent component model written in Java.JavaBeans enable developers to write reusable components once and runthem anywhere independent of platform.

Java 2 Enterprise Edition

The Java™ 2 Platform, Enterprise Edition (J2EE), defines the standardfor developing multi-tier enterprise applications. J2EE simplifiesenterprise applications by basing them on standardized, modularcomponents, providing a complete set of services to those components andhandling many application behavior details without complex programming.J2EE takes advantage of many Java 2 Platform, Standard Edition, such as“Write Once, Run Anywhere™” portability, JDBC™ API for database access,CORBA technology for interaction with existing enterprise resources anda security model that protects data even in Internet applications.Building on this base, Java 2, Enterprise Edition, adds full support forEnterprise JavaBeans™ components, Java Servlets API, JavaServer Pages™and XML technology.

Java Server Pages

The JavaServer Pages™ technology provides a quick and simple way tocreate dynamic Web content while enabling rapid development of Web-basedapplications that are server- and platform-independent. The Java™Servlet API provides Web application developers with a simple andconsistent mechanism for extending Web server functionality.

Enterprise Java Beans

The Enterprise JavaBeans specification defines an API that helpsdevelopers create, deploy and manage cross-platform, component-basedenterprise applications that work with systems currently in use.

Java Naming and Directory Interface

This provides uniform, industry-standard and seamless connectivitybetween the Java platform and one's business information assets,allowing developers to deliver Java applications with unified access tomultiple naming and directory services across the enterprise.

Java Database Connectivity

This provides programmers with a uniform interface to a wide range ofrelational databases, as well as a common base upon which higher-leveltools and interfaces can be built.

Java Messaging Services

This specification provides developers with a standard Java API forenterprise messaging services, such as reliable queuing, publishing andsubscription communication and various aspects of push/pulltechnologies.

Remote Method Invocation over HOP

RMI-IIOP provides developers an implementation of the Java RMI API overthe Object Management Group's industry-standard Internet Inter-OrbProtocol (HOP). It allows developers to write remote interfaces betweenclients and servers and implement them using Java technology and theJava RMI APIs.

XML

XML (eXtensible Markup Language) is a simplified subset of the StandardGeneralized Markup Language (SGML, ISO 8879) that provides a file formatfor representing data, a schema for describing data structure and amechanism for extending and annotating HTML with semantic information.

Secure Socket Layer API

Secure Sockets Layer (SSL) is the Internet security protocol forpoint-to-point connections. It provides protection againsteavesdropping, tampering and forgery. Clients and servers establish asecure link, or “pipe,” across the Internet to protect information thatis sent and received to ensure confidential, authentic and originalinformation exchange.

Various embodiments of the present invention having been thus describedin detail by way of example, it will be apparent to those skilled in theart that variations and modifications may be made without departing fromthe invention. The invention includes all such variations andmodifications as fall within the scope of the appended claims.

1. A method, comprising: storing, at a central system, first paymentdata relating to at least one transfer of funds to a payee, the firstpayment data comprising a payment amount and payee data, the firstpayment data being received from a first remote system and beingassociated with a payer account of a payer maintained by the firstremote system, the first remote system using a first securityinfrastructure to control access by the payer to the first remote systemto initiate the at least one transfer of funds, the first payment databeing defined after access by the payer to the first remote system toinitiate the at least one transfer of funds is granted and prior tostorage of said first payment data; generating, by the central system, atransaction identifier and associating the transaction identifier withthe first payment data; determining, at the central system, whether thepayee data is authenticated and stored at the central system; initiatinga transmission of a notification of the at least one transfer of fundsto a communication address identified by the payee data, thenotification including the transaction identifier; receiving, from auser communication device associated with the payee, a communicationassociated with the transaction identifier; after receiving thecommunication from the user communication device, in a transmission tothe user communication device, directing a browser executing on the usercommunication device to a website associated with a second remote systemto complete the at least one transfer of funds; receiving, at thecentral system, second payment data from the second remote system, thesecond remote system using a second security infrastructure to controlaccess by the payee to the second remote system in relation to the atleast one transfer of funds, the second payment data being receivedafter access by the payee to the second remote system is granted, thefirst and second security infrastructures and access to the first remotesystem and the second remote system being controlled independently ofthe central system; in a further transmission, providing informationabout the transfer of funds, including an identifier of the payer andthe payment amount, to the second remote system; and transmittingverification of the at least one transfer of funds for receipt by thesecond remote system if the payee data is thus authenticated.